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eginningiin  1993,  over  the  course  of  more 
than  a  year,  a  group  of  14  individuals  from 
Air  Force  Space  Command  and  the  Space 
and  Missile  Systems  Center  pursued  a  char¬ 
ter  established  by  senior  Air  Force  officials. 
Their  primary  goal  was  to  determine  what 
was  wrong  with  the  requirements  process 
and  make  recommendations  to  fix  it.  In  the 
course  of  developing  recommendations, 

many  experts  from  the  field  were  invited  to  present  their  perspective. 
Individuals  came  from  the  Defense  Systems  Management  College,  the 
Air  Force  Institute  of  Technology,  the  Air  Force  Office  of  Aerospace  Stud¬ 
ies,  individual  program  directors  and  managers  from  a  number  of  system 
program  offices,  different  major  command  requirements  personnel,  and 
even  a  noted  expert  and  author  in  space  requirements  and  architecture 
from  the  U.S.  Air  Force  Academy.  The  findings  were  extensive  and,  for 


Beno,  a  retired  Air  Force  lieutenant  colonel,  is  a  1974  U.S.  Air  Force  Academy  graduate  and  is 
level  III  certified  in  contracting  and  program  management.  He  is  currently  working  as  the  pro¬ 
gram  manager  for  the  Standard  Procurement  System  at  Maxwell-Gunter  Air  Force  Base,  Ala. 
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What's  wrong  with  the 
requirements  process?  Is  the 
process  still  broken? 


ease  of  interpretation,  were  divided  into  six  broad  categories: 
training;  documentation;  responsibilities/resources;  planning 
and  teamwork;  customer  satisfaction;  and  modifications,  up¬ 
grades,  and  follow-on  programs.  That  study  was  used  as  the 
basis  for  the  comments  in  this  article. 

What's  wrong  with  the  requirements  process?  Is  the  process 
still  broken?  Those  questions  raised  significant  problems  in 
the  early  1990s  and  continue  to  be  asked  today  by  people 
from  all  military  services.  The  requirements  process  is  inex¬ 
tricably  tied  to  other  key  questions  in  the  acquisition  environ¬ 
ment,  such  as  why  does  it  take  so  long  to  field  systems  and 
why  are  costs  seemingly  always  much  higher  than  predicted? 

I  would  like  to  know  if  any  of  the  problems  we  saw  in  the 
early  1990s  have  been  solved  (and  whether  any  of  the  rec¬ 
ommendations  have  been  enacted  and  are  useful).  Did  the 
new  Joint  Capabilities  Integration  and  Development  System 
approved  on  June  24, 2003,  actually  improve  anything  or  did 
the  same  problems  simply  get  rearranged  under  new  titles? 
Is  the  requirements  process  still  broken? 

In  order  to  systematically  analyze  and  provide  potential  solu¬ 
tions  to  such  a  complex  problem,  this  article  follows  a  specific 
format.  A  problem  is  asserted,  and  then  is  followed  up  with 
data,  analysis,  and,  in  some  cases,  recommendations.  All  of 
these  comments  were  derived  from  the  Space  Command 
study  accomplished  in  the  early  1990s. 


Few  people  understand  the  complex  nature  of 
the  requirements  process,  resulting  in  major 
program  problems  later  on  in  the  acquisition 
phases. 

Where  can  one  go  to  find  (study)  the  requirements  pro¬ 
cess?  Is  the  process  definitively  laid  out  in  any  documents? 
If  you  look  into  the  DoD  5000  series  or  even  the  latest 
AFI  10-6  (or  AFPD  10-601),  which  specifically  addresses 
requirements,  there  does  not  appear  to  be  anything  called 
a  requirements  process.  What  one  will  find  is  something 
called  "evolutionary  requirements  definition,"  which  basi¬ 
cally  states  that  requirements  begin  very  broadly  and  are 
more  and  more  defined  as  time  goes  on.  Some  very  top- 
level  requirements-type  activities  are  mentioned  (such  as 
the  mission  area  assessment  [MAA],  also  known  as  "strat- 
egy-to-task"  analysis),  but  how  one  actually  accomplishes 
the  tasks  is  left  to  the  reader— not  very  edifying.  There 
is  also  mention  of  a  planning  process  and  an  acquisition 
process,  and  both  seem  to  contain  portions  of  what  one 
might  assume  are  requirements  tasks. 

Fortunately,  since  these  observations  were  noted  in  the 
1994  timeframe,  some  progress  has  been  made.  The  old 
requirements  regulation  (AFR  57-1)  indicated  that  MAAs 
were  a  continuous  process.  One  could  assume  from  that 
statement  that  a  major  command's  planning  shop  would 
have  a  cadre  of  professionals  accomplishing  the  tasks.  The 
facts  were  that  some  major  commands  had  never  accom¬ 
plished  a  MAA.  Since  then,  some  major  commands  have 
been  putting  more  resources  into  upfront  requirements 
analysis  such  as  MAAs,  so  there  appears  to  be  some  prog¬ 
ress.  Nonetheless,  in  order  to  determine  if  anything  has 
changed,  shouldn't  DoD's  first  focus  be  on  how  effective 
Services  are  in  ensuring  that  their  people  understand  the 
process? 

Today,  many  senior  leaders  are  exposing  the  methodology 
of  retired  Lt.  Gen.  Glenn  Kent,  director  of  the  Weapons 
Systems  Evaluation  Group  in  the  1970s.  His  strategies-to- 
task  process  appears  to  have  been  embraced  by  much  of 
the  Air  Force  senior  leadership,  if  not  by  all  of  DoD,  as  the 
way  to  link  national  objectives  to  acquisition  programs. 
Without  that  linkage,  it  is  argued  that  the  need  for  new 
weapons  systems  cannot  be  connected  to  battlefield  out¬ 
comes  and,  as  a  result,  will  not  receive  the  priority  required 
in  the  program-planning-budgeting  system  to  obtain  funds. 
Review  of  the  systems  under  development  indicate  few 
systems  underwent  that  or  any  similar  type  of  approach. 

Few  people  follow  the  process,  even  at  the 
macro  level,  as  laid  out  by  regulation. 

A  frustrating  fact  is  that  for  those  few  who  understand  the 
process,  it  is  rarely  followed.  The  requirements  process 
starts  with  taking  what  is  known  of  national  objectives 
and  determining  what  the  military  objectives  should  be. 
In  order  to  accomplish  those  objectives,  the  military  has  to 
be  able  to  accomplish  specific  tasks.  That  is  the  MAA  pro- 


Defense  AT&L:  July-August  2010 


36 


cess  (strategy-to-task  analysis).  Commanders  determine 
the  objectives  each  year  using  a  variety  of  techniques  and 
sources  of  data,  to  include  the  Defense  Planning  Guidance, 
which  lays  out  broad  objectives  for  the  military.  It  is  the 
theater  commander's  (or  major  command's/combatant 
commander's)  job  to  translate  that  guidance  into  a  list  of 
specific  tasks.  Once  a  list  of  tasks  is  developed,  the  forces 
to  implement  the  tasks  are  determined— called  "task  to 
need,"  or  mission  need  analysis  (MNA).  Duringthat  phase, 
operational  scenarios  are  modeled,  and  computer  simula¬ 
tions  run  using  existing  and  planned  forces  to  meet  the 
objectives  of  the  Defense  Planning  Guidance. 

Those  wargaming  exercises  result  in  success  or  failure. 
Failures  result  first  in  changes  in  tactics,  organization,  op¬ 
erational  concepts,  doctrine  or  training,  and  non-material 
solutions.  Significant,  and  hopefully  obvious,  is  the  need 
for  a  concept  of  operations,  or  CONOPs  (i.e.,  how  forces 
are  employed  and  deployed,  maintained,  operated,  pre¬ 
positioned,  etc.)  The  very  last  consideration  to  resolve  a 
deficiency  is  a  material  solution.  That  requires  the  writing 
of  a  mission  need  statement  (MNS),  which,  in  very  broad 
terms,  indicates  the  mission  deficiency.  It  is  not  solution- 
oriented  although  it  may  list  potential  alternatives.  All  of 
that  information  can  be  found  in  the  regulations  (if  you 
look  hard  enough),  so  what's  the  problem?  The  answer  is 
simple:  It  is  rarely  followed.  There  are  many  cases  in  which 
the  MAA,  CONOPs,  or  MNA  is  not  accomplished,  but  a 
requirement  is  identified  and  a  MNS  is  written!  Flow  does 
that  happen? 

There  are  two  ways  in  which  a  MNS  might  be  written  with¬ 
out  going  through  the  MAA/MNA  process.  First,  it  could 
be  that  a  new  technology  has  been  developed  and  a  user 
wants  to  take  advantage  of  it.  Secondly,  a  fielded  product 
may  not  be  performing  as  previously  planned  and  a  sub¬ 
stitute  must  be  found.  Unfortunately,  most  MNSes  result 
from  technology  push,  and  that  causes  its  own  problems. 

Technology  MNS  without  linkage  to  operational  objectives 
and  the  rigors  of  the  MAA/MNA  process  results  in  prod¬ 
ucts  that  are  difficult,  if  not  impossible,  to  assess  in  terms 
of  operational  suitability.  If  the  mission  effectiveness  of  the 
end  product  was  not  run  through  the  operational  scenarios 
(models  and  wargames),  acquisition  personnel  won't  know 
how  well  the  system  meets  the  need.  That  is  the  first  and 
foundational  problem  with  acquisition  programs  today. 

There  is  a  failure  between  user  and  developer 
to  communicate  or  work  as  a  team. 

The  question  the  developer  asks  should  not  be  just,  "What 
does  the  user  want?”  as  if  anything  asked  for  will  be  pro¬ 
vided.  In  these  times  of  defense  spending  cutbacks,  cost 
is  a  major  limiting  factor.  A  good  customer-supplier  rela¬ 
tionship  demands  a  more  detailed  understanding.  Better 
and  more  fundamental  questions  are,  "What  is  the  mission 
(operational  objectives,  environment,  etc.)?''  and  "How 


do  I  know  when  the  product  is  good  enough?”  If  the  user 
does  not  provide  enough  operational  information— such  as 
a  CONOPs— and  the  mission  objectives  to  the  developer, 
then  the  user  is  not  going  to  get  an  optimal  system.  That 
is  because  with  the  seemingly  omnipresent  shortage  of 
funds,  tradeoffs  almost  always  have  to  be  made  some¬ 
where  in  the  performance  and  supportability  regimes. 

Some  users  do  not  feel  it  is  important  that  the  developer 
know  the  details,  and  some  developers  conversely  do  not 
feel  the  user  needs  to  know  much  about  the  design.  That 
is  flawed  thinking.  Systems  are  complex,  and  decisions  and 
tradeoffs  due  to  performance  and  cost  must  be  made  con¬ 
tinuously.  Design  trades  must  have  the  support  of  the  user. 
The  solution  is  simple— complete  communication  using  an 
integrated  product  team  approach. 

The  user  is  now  in  charge  of  all  work  up  to 
Milestone  1  (now  called  Milestone  B) — and  that 
is  a  fundamental  mistake. 

Both  the  material  solution  analysis  (MSA)  phase  (MAA/ 
MNA/MNS)  and  the  technology  development  phase  prior 
to  Milestone  B  are  run  by  the  user.  That  is  a  mistake  be¬ 
cause  the  functions  that  occur  during  the  phase  are  ac¬ 
quisition-specific.  For  example,  alternatives  are  analyzed, 
cost  reports  are  generated,  tradeoffs  are  conducted,  and 
preparation  for  the  Milestone  B  Defense  Acquisition  Board 
review  with  all  the  associated  acquisition  documentation 
must  take  place. 

One  of  the  documents  that  must  be  generated  is  the  cost 
and  operational  effectiveness  report  (cost  and  operational 
effectiveness  analysis  [COEA],  now  called  the  analysis  of 
alternatives  [AoA]).  Some  would  say  that  the  COEA  is  the 
most  critical  document  to  be  developed  in  that  it  is  the 
basis  for  the  commander's  decision  on  which  alternative  to 
pursue.  The  user,  in  most  cases,  does  not  have  the  techni¬ 
cal  or  business  experience  to  lead  those  efforts.  In  addition, 
they  do  not  have  the  funds  to  pay  for  the  COEA,  as  research 
and  development  dollars  are  used  to  fund  contractor  stud¬ 
ies  that  operational  commands  do  not  have. 

Weapons  are  complex  and  costly.  To  ensure  that  proper 
decisions  are  made,  the  phase  should  be  overseen  by  those 
who  understand  the  acquisition  and  requirements  process, 
which  in  itself  is  very  complex.  An  analogy  is  that  because 
I  drive  a  car,  I  should  be  able  to  build  one.  It  doesn't  make 
sense.  This  position  does  not  mean  the  final  decisions  and 
the  structure  of  the  acquisition  should  not  be  approved 
by  the  major  command/combatant  commander.  The  user 
must  have  the  final  decision. 

If  we  must  continue  with  the  process  as  is,  then  the  user 
commands  must  be  trained  in  not  only  the  requirements 
process  but  the  acquisition  process  as  well.  The  complex¬ 
ity  of  the  acquisition  process  coupled  with  the  turnover  in 
user  personnel  does  not  bode  well  for  success  in  this  area. 
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Historically,  by  the  time 
systems  are  fielded,  10  to  15 
years  have  passed  and  the 
threat  has  changed.  What 
causes  this?  Part  of  the 
problem  is  the  process  itself. 


The  impact  oi  unscientific  (political)  decisions 
is  a  major  problem. 

All  of  DoD  labors  under  a  process  that  is  fraught  with  spe¬ 
cial  interests,  service  parochialism,  personalities,  and  dis¬ 
regard  or  lack  of  understanding  on  the  impact  of  arbitrary 
decisions.  There  have  been  numerous  studies  and  reports 
on  that  problem,  from  the  inspector  general,  the  Defense 
Management  Review,  and  the  Government  Accountabil¬ 
ity  Office  as  well  as  the  Goldwaters-Nichols  Act,  all  ad¬ 
dressing  a  variety  of  concerns  for  the  process  by  which 
requirements  are  formulated.  Mechanisms  can  be  set  up 
to  minimize  the  impact  of  what  well  call  "unscientific"  deci¬ 
sions,  but  the  naked  truth  is  that  these  problems,  in  some 
cases,  do  not  lend  themselves  to  an  easy  solution.  Rather, 
they  are  issues  that  have  to  do  with  human  nature  and,  as 
such,  are  difficult  at  best  to  regulate. 

At  a  minimum,  decisions  must  be  documented  in  a  trace- 
ability  tool  that  links  design  back  to  the  original  deficiency. 
The  traceability  tool  provides  the  pedigree  of  the  decision. 
Although  these  tools  existed  in  1991,  few  were  employed. 
Requirements  traceability  tools  should  be  mandated  on 
all  programs. 

Weapons  systems  should  result  from  the  study 
of  alternatives  (COEA/AoA),  which  should  be 
composed  of  potential  solutions  from  all  Ser¬ 
vices  (not  just  one). 

Effective  concept  analysis  involves  looking  at  the  potential 
of  widely  differing  systems— including  Army,  Navy,  or  Air 
Force  programs— to  solve  the  deficiency.  Unfortunately, 
that  rarely  happens.  Instead,  depending  on  which  Service 
is  leading,  the  study  of  alternatives  usually  involves  look¬ 
ing  at  similar  systems.  For  example,  instead  of  looking  at 
a  ship  versus  a  satellite  versus  a  tank,  the  tendency  is  to 
look  at  five  different  types  of  ships.  The  Joint  Requirements 
Oversight  Council  (JROC)  was  formed  for  several  reasons, 
but  in  particular  for  ensuring  the  MNS  looked  at  building 
systems  for  multiple  Services  for  the  simple  purpose  of 


saving  money.  There  is  a  general  sense  that  for  whatever 
reason,  the  JROC  is  not  solving  this  specific  problem.  The 
system  is  not  set  up  to  take  the  mission  deficiency  of  one 
Service  and  force  its  use  on  another. 

Services  see  mission  deficiencies  and  the  justifications  for 
new  starts  as  their  ticket  into  the  budget  process.  It  is  dif¬ 
ficult  to  expect  military  services  to  advocate  a  system  that 
potentially  would  result  in  another  military  service  obtain¬ 
ing  the  program.  Call  it  parochialism,  Service  loyalty,  what¬ 
ever;  it  is  just  not  going  to  happen  unless  an  organization 
above  the  Service  level  does  it.  Currently,  both  the  JROC 
and  the  Defense  Acquisition  Board  have  the  opportunity  to 
review  and  ensure  that  other-than-Service-unique  alterna¬ 
tives  are  addressed  in  the  MSA  phase  (prior  to  Milestone 
A).  As  such,  should  DoD  explore  the  benefits  of  accom¬ 
plishing  (or  at  least  certifying)  all  tools  (i.e.,  modeling  and 
simulation,  wargaming  assumptions,  etc.)  for  the  purpose 
of  ensuring  deficiencies  and  potential  solutions  are  prop¬ 
erly  developed  at  the  DoD  level? 

Sometimes  requirements  are  generated  to 
justify  the  weapons  system  and  not  to  resolve  a 
mission  deficiency. 

For  example,  in  one  aircraft  purchase,  the  number  of  air¬ 
craft  to  be  produced  was  based  on  the  the  ground  cover¬ 
age  of  its  radar.  A  later  analysis  pointed  out  that  based  on 
the  given  radar  coverage,  the  number  of  aircraft  bought 
could  be  reduced;  however,  instead  of  reducing  the  num¬ 
ber  of  aircraft  bought,  the  radar  coverage  requirement  was 
reduced,  resulting  in  the  need  for  the  original  number  of 
aircraft.  That  illustrates  once  again  the  need  for  the  trace- 
ability  of  requirements  to  the  mission  deficiency,  not  the 
weapons  system. 

It  is  acknowledged  by  Pentagon  bureaucrats  that  the  mili¬ 
tary  services'  real  battle  is  not  the  next  war,  but  the  next 
budget  exercise.  In  order  to  cut  inefficiencies  and  bogus 
requirements,  connectivity  of  the  requirement  to  measures 
of  effectiveness— i.e.,  battle  outcomes— must  be  shown. 
Major  commands  are  not  very  effective  at  obtaining  re¬ 
sources  using  strategy-to-task  analysis,  and  this  was  also 
a  draft  finding  of  the  Air  Force  Studies  Board  during  its 
pre-milestone  1  (now  Milestone  B)  review. 

Why  all  these  problems?  A  couple  reasons  come  to  mind. 
Firstly,  modeling  and  simulation  requires  a  certain  level  of 
assumption.  Changes  in  those  assumptions  can  make  the 
difference  between  having  or  not  having  a  need.  Since  the 
major  commands  are  running  the  models,  Congress  may 
view  it  as  the  wolf  guarding  the  hen  house.  Secondly,  the 
Air  Force  hasn't  had  too  many  programs  that  resulted  from 
M  AA/MN  A.  Most  have  been  top-down  (i.e.,  Congress,  the 
president,  etc.)  directed  (outside  the  process)  and  gener¬ 
ally  based  more  on  the  availability  of  technology  or  the 
need  to  replace  an  aging  system.  The  notion  that  major 
commands  are  out  there  annually  running  fully  capable 
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and  accepted  Office  of  the  Secretary  of  Defense-endorsed 
models  is  not  widely  accepted. 

Traceability  tools  that  take  lower-level  require¬ 
ments  and  trace  them  back  to  the  initial  need 
are  not  being  used. 

This  problem  was  noted  elsewhere  in  this  article,  but  it 
needs  to  be  emphasized.  Traceability  tools  provide  a  struc¬ 
tured  technique  for  identifying  performance  requirements 
and  system  concepts;  providing  uniform  communication  of 
requirements;  providing  baseline  data  for  system  design,  lo¬ 
gistics  support,  test  activities,  and  training  and  operations; 
and  defining  source  requirements  for  end-item  specifica¬ 
tions.  The  tools  document  the  rationale  and  the  process  for 
requirements  from  the  M  AA  to  the  operational  requirements 
document  (ORD,  now  call  the  initial  capabilities  document,  or 
ICD).  Currently,  there  is  no  technique  that  does  that,  resulting 
in  a  lack  of  traceability  and  confusion.  Traceability  tools  should 
be  mandated. 

The  requirements  process  takes  too  long. 

Historically,  by  the  time  systems  are  fielded,  10  to  15  years 
have  passed  and  the  threat  has  changed.  What  causes  this? 
Part  of  the  problem  is  the  process  itself,  which  will  be  ex¬ 
plained  in  a  moment.  Both  the  documentation  requirements 
and  budget  process  adds  to  this  problem. 

Contrary  to  popular  belief,  program  stretchouts,  which  have 
for  years  been  attributed  to  Congress,  were  shown  through  a 
report  (Betti  Streamlined  Acquisition  Initiative)  to  actually  be 
the  result  of  internal  DoD  realignments  of  funds.  The  process 
is  DoD's  to  fix. 

One  of  the  problems  that  lead  to  extended  timelines  is  a  lack 
of  upfront  planning.  Upfront  planning,  to  include  such  things 
as  assessing  alternatives,  accomplishing  trade  studies  for 
performance  versus  cost,  etc.,  is  essential  to  get  the  most 
bang  for  the  buck.  Any  student  of  acquisition  or  Lean  engi¬ 
neering  will  tell  you  that  there  is  a  direct  relationship  between 
schedule  (and  cost)  savings  and  early  problem  resolution.  If 
this  is  the  case,  why  then  is  the  funding  for  the  MSA  phase 
so  minuscule? 

The  old  DoDI  5000.1  stated  that  the  under  secretary  of  de¬ 
fense  for  acquisition  would  provide  funding  for  the  phase  0 
(now  MSA  phase)  activity,  yet  in  essence,  the  funding  was  so 
small  as  to  be  nonexistent.  (The  new  DoDI  5000.01,  dated 
May  12,  2003,  no  longer  addresses  this  issue.)  Funding  for 
phase  0  activities  had  to  be  begged,  borrowed,  and  stolen 
from  other  sources.  That  results  in  minimum  alternatives 
being  reviewed  and/or  trade  studies  that  are  not  completely 
accomplished. 

Obviously,  the  need  for  upfront  planning  is  a  tenet  accepted 
by  all.  Unfortunately,  either  the  means  is  undefined  or  the 
will  is  lacking.  Initial  project  direction  is  absolutely  crucial  to 
effective  and  efficient  acquisition  of  programs.  The  need  for 


phase  0  (now  the  MSA  phase)  funding  must  be  planned  and 
budgeted  by  the  users  without  the  worry  of  having  the  money 
cut  for  other  purposes.  As  mentioned,  the  user  currently  has 
that  responsibility  but  cannot  use  research  and  development 
funds— a  real  catch-22. 

Major  acquisition  programs  are  characterized  by  long 
timelines.  Unfortunately,  these  timelines  are  unnecessarily 
stretched  out  by  the  bureaucracy,  e.g.,  the  documentation 
coordination  cycles  of  the  ORD/ICD,  COEA/AoA,  acquisition 
program  baseline,  etc.  Disconnects  with  any  of  those  docu¬ 
ments  can  cause  major  perturbations  in  the  schedule. 

The  requirements  documents  are  improperly  ac¬ 
complished. 

There  appears  to  be  a  mentality  among  all  users  to  fill  out 
the  first  ORD  (now  ICD)  as  completely  as  possible  and  as 
soon  as  possible.  The  ICD  is  the  place  for  listing  critical  per¬ 
formance  parameters;  however,  there  is  no  need  to  have  the 
initial  ORD  reflect  everything  quantitatively.  The  initial  ICD, 
created  prior  to  the  material  development  decision  (prior  to 
the  start  of  the  MSA  phase),  has  been  inappropriately  used 
to  generate  the  system  specification  because  of  its  detail  (in 
some  other  programs,  it  is  not  even  signed  when  the  system 
specification  is  released  to  industry).  This  mentality  drives 
program  cost  and  reduces  performance  tradeoff  opportuni¬ 
ties.  The  Army's  Training  and  Doctrine  Command  approach 
is  to  attempt  to  limit  the  ORD  to  one  page.  In  contrast,  AFI 
10-6  has  nine  pages  of  just  instructions  on  what  should  be  in 
the  ORD.  The  final  ORD,  indeed,  needs  to  have  that  level  of 
detail,  but  not  the  initial  one.  Instruction  needs  to  be  provided 
to  the  users  on  what  is  and  is  not  acceptable  in  the  initial  ORD. 
Air  Force  Directorate  of  Operational  Requirements  concurs 
that  initial  ORDs  are  too  detailed.  Processes  and  examples 
of  how  to  determine  critical  performance  parameters  should 
be  included  in  the  next  AFPD  10-601  update.  It  is  imperative 
that  the  developer  have  some  room  to  trade  off  requirements 
in  order  to  obtain  the  best  mix  of  cost  and  performance.  The 
key  is  that  the  user  must  trust  the  developer  to  provide  the 
various  options.  Using  the  entire  team  to  fill  out  the  ORD  is 
the  right  direction  in  solving  this  problem. 

To  create  an  ORD  without  the  other  team  members  results  in 
two  of  the  current  problems  we  have  with  the  system.  First,  it 
takes  47  weeks  to  get  an  ORD  coordinated.  That  is  too  long. 
The  reason  is  the  users  have  to  "inspect  in"  the  quality  of 
the  draft  versus  ensuring  the  quality  upfront  using  a  team 
approach  to  development.  Second,  the  other  Service  users 
(when  there  is  more  than  one,  such  as  for  the  GPS  program) 
are  frustrated  at  the  requirements  process  because  their  re¬ 
quirements  are  either  relegated  to  secondary  status  or  are  not 
addressed  at  all.  That  results  in  some  users  going  directly  to 
the  acquisition  community  to  be  heard.  Bypassingthe  "execu¬ 
tive"  user  causes  its  own  unique  communications  problems. 

Finally,  there  is  little  written  procedure  for  how  to  accomplish 
the  documentation,  to  include  the  M  AA,  MN  A,  and  COEA.  It 
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was  discovered  that  some  documents  are  created  not  as  part 
of  the  process  but  after  the  fact  as  backfill  or  "box-checks" 
for  those  that  are  missing.  The  CONOPs  often  fall  into  this 
category  as  well.  When  you  put  poorly  trained  personnel 
together  with  a  lack  of  sufficient  written  guidance,  the  result 
most  likely  will  be  negative. 

Communication  must  be  open  and  honest. 

Without  a  clear  understanding  of  roles  and  a  process  for 
ensuring  anomalies  are  processed  according  to  an  agreed-to 
methodology,  confusion  will  continue  to  confound  the  par¬ 
ticipants  in  the  process.  One  way  of  reducing  the  size  of  this 
problem  is  to  put  the  rules  of  engagement  in  writing— e.g., 
employ  a  charter,  signed  off  by  all  the  participants. 

Inhibitors  to  careful  planning  and  teamwork  are  decisions  by 
individuals  without  regard  for  analysis  or  trades.  Other  rea¬ 
sons  for  seemingly  arbitrary  decisions  are  the  need  to  justify 
the  expense  of  existing  architectures,  to  include  base  operat¬ 
ing  support  facilities.  A  structured  and  analytical  approach  to 
all  requirements  is  required  versus  the  arbitrary  decision  of 
an  individual.  Uninformed  (and  sometimes  capricious)  deci¬ 
sions  could  be  curtailed  if  they  have  to  meet  the  scrutiny  of 
fiduciary  prudence.  One  of  the  findings  of  earlier  studies  is 
that  many  decisions  are  made  by  fiat,  in  contradiction  to  the 
results  of  modeling. 

Cost  is  driven  up  by  the  instability  ot  require¬ 
ments. 

Requirements  often  change  when  people  are  reassigned  and 
new  philosophies  are  introduced.  This  problem  indicates  that 
requirements  can  be  more  personality  dependent  than  sce¬ 
nario  driven.  A  similar  problem  is  requirements  creep,  which 
occurs  when  a  new  technology  is  being  marketed  either  by 
a  lab  or  by  industry.  They  know  if  they  can  get  the  need  for 
their  system  into  the  requirements  document,  it  will  ensure 
a  business  base  for  years  to  come. 

The  Navy  is  very  proactive  in  ensuring  that  new  requirements 
without  associated  funding  are  rejected.  Instability  and 
creeping  requirements  and  the  problems  they  cause  are  an¬ 
other  good  reason  why  decisions  must  be  documented  and 
arrived  at  by  a  given  process,  not  the  whims  of  individuals. 
Whims,  like  people,  change.  Change,  without  understanding, 
causes  confusion  and  frustration  as  well  as  increased  cost. 

Training  and  experience  are  critical. 

Without  a  firm  understanding  for  the  technical  issues  raised, 
experience  in  writing  requirements,  and  a  good  knowledge 
of  the  budget  process,  military  officials  can  get  lost  in  the 
requirements  process— and  they  frequently  do!  Most  of  the 
time,  the  individuals  actually  writing  the  requirements  are  ju¬ 
nior  officers.  That  results  in  requirements  that  tie  very  poorly 
to  system  utility.  The  problem  is  not  only  with  the  junior  of¬ 
ficers.  Many  senior  officers  are  not  aware  of  the  impact  of 
their  requirement  decisions  on  the  process  To  hold  a  critical 
position  in  the  requirements  process,  an  individual  must  be 


Questions  For  Readers 

•  Do  you  feel  people  today  understand  the  re¬ 
quirements  process? 

■  The  names  of  the  processes  have  changed;  have 
the  results?  Is  there  a  system  in  place  to  develop 
requirements  using  some  form  of  strategy-to- 
task  analysis?  Is  it  better? 

•  Do  you  believe  the  integrated  product  develop¬ 
ment  is  used  effectively  in  DoD? 

•  Are  document  processing  times  still  taking  inor¬ 
dinate  amounts  of  time? 

•  What  changes  have  occurred  to  improve  the 
acquisition  knowledge  of  the  end  users? 

•  Are  program  management  offices  able  to  trace 
requirements  back  to  credible  source  data  (that 
drove  the  acquisition  initially)? 

■  How  effective  is  the  process  today  in  addressing 
cross-Service  solutions? 

■  What  percentage  of  new  programs  is  the  result 
of  warfighting  shortfalls  versus  being  top-down 
directed? 

•  Where  does  one  go  now  to  see  templates  and 
find  assistance  with  documentation? 

•  Are  charters  employed  to  establish  roles  and 
responsibilities? 

•  Are  there  minimum  levels  of  competence 
required  today  to  hold  positions  in  requirements 
positions? 

•  Did  the  elimination  of  many  acquisition  profes¬ 
sional  positions  in  the  early  2000s  make  the 
requirements  process  worse? 

•  What  can  be  done  to  fix  this  process,  and  does  it 
need  to  be  fixed? 


trained  and  a  obtain  level  of  individual  competency.  If  pre- 
Milestone  B  activities  are  not  going  to  be  returned  to  the 
developing  agencies,  user  personnel  must  become  proficient 
in  the  acquisition  field. 

Three  things  must  occur  to  ensure  competency.  First,  a 
certain  level  of  experience  (time  in  position)  in  the  require¬ 
ments/acquisition  process  must  be  mandated.  Secondly,  the 
problems  and  processes  associated  with  requirements  and 
the  problems  associated  with  managing  multi-user  programs 
must  be  developed  and  provided.  Finally,  there  should  be  a 
method  to  assess,  both  before  and  during  tenure,  an  individu¬ 
als  ability  to  accomplish  the  tasks.  This  can  be  accomplished 
using  either  oral  or  written  (e.g.,  tests)  methods  or  through 
customer  feedback  metrics. 

These  were  the  problems  that  existed  in  1993— has  anything 
changed? 


The  author  welcomes  comments  and  questions  and  can  be 
contacted  at  mikael.beno@gunter.af.mil. 
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